This invention relates to graphical user interface (GUI) elements, in particular containers of GUI elements such as parent windows, forms and dialog boxes. The invention dynamically adds resizing semantics to GUI objects (containers) that do not already contain such information.
Many computer operating systems generate window-based graphical user interfaces (GUIs). The operating systems generally provide tools to allow developers to generate windows with controls called dialogues. Operating systems may provide other kinds of user interface elements such as forms as well. Referring to FIG. 1, a dialogue box includes the controls: an edit box 10, a list box 20, and a static 30, a check box 40, and a combo box 50. The edit box 10 provides a space for the direct entry of text. In the example of FIG. 1, the edit box 10 allows a user to enter the name and/or path for a file. The list box 20 allows the user to select a predefined item from a list. The static 30 is simply a label. The check box 40 allows an item to be selected independently of other items, each corresponding to another check box. Most dialogue boxes also have at least one button 60 to invoke a particular command.
With larger monitors and higher resolution displays, users are likely to find it more useful to expand the length, for example, of a list box 20 so that more content (including controls) is displayed. Since all dialogue boxes must be defined for the smallest standard screen size and resolution, users with larger screens would likely prefer to take advantage of their increase screen area by displaying more information, thereby making their interfaces more useful.
A dialogue box can be defined by developers so that the dialogue box can be resized and its contents redistributed to take advantage of the new size. To define the dialogue features, a developer uses a resource editor to define the layout and characteristics of the dialogue box. A resulting resource file contains detailed specifications that define the controls and which parts of the box can be scaled and along which axes. The use of resource files allows for changes to be made to the arrangement and content of dialogue boxes and their controls without the need to modify the application code that displays the controls. The controls corresponding to the labels of the dialogue box can be changed by simply modifying the resource file for the particular dialogue box. The application can then be re-built without recompiling and, when subsequently executed, the application will have the operating system open the resource file and generate the dialogue. The process of generating the dialogue may involve reading the resource file and generating a derivative memory image that is used to create the dialogue rather than stepping through the resource file in real time as the dialogue is actually generated.
The need to specifically define the resizing characteristics of the dialogue arises because only some of the controls 10-60 can be expanded in a useful way. For example, expanding the dialogue box to increase the size of each feature, including fonts, would not allow more information to be displayed. Operating systems generally provide mechanisms for defining resizable dialogue boxes, but the code for defining such boxes is complex and most developers would prefer the expedient of avoiding the complexity of such expense. Developers may also already have a large number of dialogues that are already defined. To modify these to make them resizable requires a substantial amount of additional work. Also, any time the dialogues are revised to add new controls, the whole set of resizing code must revised to be compatible with the new controls.
Many applications already allow users to change the font size of the view of a document. The standard font sizes of the operating system user interface can also be changed. But this may not enhance the dialogue boxes or controls as desired.
An operating system program allows dialogue boxes, defined without any explicit resizing parameters, to be resized appropriately to the types of controls contained within them. The approach is to xe2x80x9cwalk-throughxe2x80x9d the dimensional definitions for the controls, their sizes and positions, and the dimensions of the dialogue box itself. With this information, rows and columns are defined and identified as resizable. When the dialogue box dimensions are changed, the additional length is distributed among the resizable rows and columns. According to the method, only rows, only columns, both rows and columns, and neither rows nor columns are identified as resizable. The resizing command is received by placing the pointing device at the edges or corners of the boxes in the well-known fashion. The pointer is hot tracked and changes shape to indicate the allowed dimensional changes for the dialogue. Thus, horizontal, vertical or diagonal double arrow may appear when the pointer is moved over the corner, as appropriate.
The method involves making a set of specifications about the resizing behavior of the various types of controls. For example, buttons and statics do not resize. List boxes can grow in length and height. Edit boxes can get wider, but not taller. In a preferred implementation, the walk-through occurs when the dialogue is ready to be displayed. When the application calls an operating system function to display the dialogue, it calls a particular API, in response to which particular messages are sent (most of the messages may be internal, for example, the particular font to be used). During that message, the operating system determines what controls are defined for the dialogue. The operating system thus essays the resource file for the dialogue, or a memory image derived from it, to define columns and rows partitioning the various controls. One set of columns and rows corresponds to borders. Using a predefined set of characteristics for each type of control, the operating system determines which columns and which rows are resizable. From this information, it is determined along which axes the dialogue can grow.
Once the dialogue is generated on the screen, during any messages generated when the pointer is over a border, the pointer is changed to indicate how the dialogue can change size. If the pointer is over a corner and the dialogue can grow, the pointer changes to a double-headed arrow aligned with the axis to which growth is restricted, or, if the dialogue can grow in along both axes, the pointer is changed to a diagonal double-headed arrow.
Upon a message to change the size of the dialogue, the growth is restricted to the axis or axes permitted to grow. If the dialogue cannot grow, the size takes its initial settings.
Upon a message indicating new dimensions, the additional size is allocated evenly among the resizable columns/rows. The controls are then reattached to the columns and rows. If the controls are resizable, they are stretched to fill the respective stretched column or row. The dialogue is then repainted with the new sizing information.
In alternative embodiments, the sizing information is given as a global operating system parameter. For example, all dialogues may be scaled by a fixed percentage, wherever possible. The global operating system parameter can be coupled to the screen resolution so that when the user changes the screen from 640xc3x97480 to 800xc3x97600, all dialogues are automatically scaled, to the extent possible, by a factor of 1.25.
Using the invention, no additional coding for the dialogues is necessary to allow such resizing. Also, the method uses a minimum of additional data to insure that processing is speedy. In addition, the particular set of resizing rules insures that the resized dialogues are visually agreeable and that the additional size available exploited to maximum ergonomic advantage. This is done by providing the following.
All controls resize in both directions except: check boxes, group boxes, statics, combo boxes, and edit boxes.
Edit boxes and combo boxes may become wider only.
Any buttons along a bottom edge or right edge will maintain their spacing after resizing.
Any buttons along a right edge are identified with a top, center, or bottom position and maintained at the respective top, center, or bottom position after resizing.
Any buttons along a bottom edge are identified with a right, left, or middle position and maintained at the respective right, left, or middle position after resizing.
Columns and rows are rated for resizing according to a weighting factor that is +2 for each resizable control and xe2x88x921 for each non-resizable control and the column or row is designated resizable if its total weight is zero or positive.